home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Atari Mega Archive 1
/
Atari Mega Archive - Volume 1.iso
/
telecomm
/
opterm05.lzh
/
AUTO
/
TURBOCTS.DOC
next >
Wrap
Text File
|
1991-04-13
|
9KB
|
199 lines
TURBO CTS
Version 1.32
Copyright (C) 1989 by Bill Penner
First a statement: USE THIS SOFTWARE AT YOUR OWN RISK! THIS
PROGRAM MAY BE FREELY DISTRIBUTED AS LONG AS THE PROGRAM REMAINS
UNMODIFIED AND THIS DOC FILE REMAINS WITH THE PROGRAM. THIS PROGRAM
MAY !!NOT!! BE SOLD, HOWEVER, MAY BE INCLUDED ON CLUB DISKS WHICH ARE
SOLD FOR A SMALL FEE. YOU USE THIS SOFTWARE AT YOUR OWN RISK. I
ASSUME NO RESPONSIBILITY FOR ANY LOSS, DIRECTLY OR INDIRECTLY FROM USE
OR POSSESION OF THIS PROGRAM.
Since the ATARI ST was released in 1985 the computer has been
advertised as supporting RS-232 Clear to Send and Request to Send
(CTS/RTS) protocol. The truth is that the computer never has
sucessfully supported this. Even with the changes taking place in TOS
1.4, the April version of the ROM's still contain several bugs in the
RS232 routines which have made RTS/CTS flow control inoperative.
Currently most RS-232 interfaces only require three wires to be
connected between the computer and a peripheral (such as a modem or
serial printer). These lines would be the transmit data, receive data,
and ground. The transmit data line would carry the information from
the computer to the peripheral device and receive data would bring data
into the computer from the peripheral. Some devices operate slowly,
such as printers, and the computer can send out data faster than the
device can use it. To be able to work best with a computer, the
external device normally uses some form of buffering to store several
bytes (characters) of data (sometimes up to 256K bytes or more). If
the buffer was always larger than the amount of information no problem
would occur, but most devices will allow you to send more data out than
the buffer would be able to hold. To handle this, a form of
"handshaking" is required. For the RS-232 interface one of two
protocols of handshaking are normally used. Currently, the more
popular one is the XON/XOFF protocol. In this protocol, when a buffer
is nearly full, the device will send out a character as would be sent
out by pressing Control and S (Ctrl-S). When the buffer has emptied to
some point, the device will send out a Ctrl-Q to tell the other device
to start sending again. Communication with most BBS's will also allow
the user to stop the sending of text from the BBS by pressing Ctrl-S
from the terminal and then Ctrl-Q to continue the text again. The
other protocol is an older one in which two more wires are added to the
RS-232 interface for RTS and CTS signals. These operate similar to the
XON/XOFF protocol except that instead of sending some data back down
the line to tell the other device to stop sending data, a line is
changed from low to high. The line being sent from the computer to
tell an external device to stop sending is called Request to Send
(RTS). The line coming from an external device to the computer to tell
the computer to start or stop sending is called Clear to Send (CTS).
With most peripheral devices being smart (based on a
microprocessor or microcontroller), and the serial speeds being fairly
slow (110 to 9600 baud), XON/XOFF was easier to implement and required
less hardware. But, now with modem speeds increasing, several
companies are implementing RTS/CTS flow control. The US Robotics 9600
and 14400 baud modems have MNP data compression available when the
modem to computer RS-232 speed is set at 19200 baud, but to handle the
19.2K baud speed, the modem uses RTS/CTS flow control. The ATARI ST
ROM's have pretended to support this mode, but bugs in all versions of
TOS have prevented RTS/CTS from working, including the April version of
TOS 1.4 ROM's.
Upon the request of Don P. (STARBASE), I began to work on a fix
for the problem. At first glance the problem was a simple one, only to
trap the characters being sent to the modem and check for CTS being
low. I wrote a couple of accessories and programs which did this.
They were called CTSFX100, CTSFX101, CTSFX102, and CTSFX103. The
result is that they worked for some pieces of software like Flash and a
couple of other problems. While working on the program, I was
optimising routines and making the program faster. This only resulted
in showing that my method of fixing the problem was greatly in error.
I was simply grabbing the characters as they were being sent to the
output buffer and between the operating system, my software, and the
terminal or BBS program, the transfer speed was less then 19200 baud so
the buffer would never get filled up and my filter was working. But
after optimising several portions, the speed increased to the point of
making my program useless since the buffer would fill up the output
buffer and when CTS changed, my program would stop placing data in the
buffer, but then the computer would continue to send out the rest of
the buffer. In the documentation I wrote with the program, I included
my phone number. The program was distributed on F-Net and within a
couple of days, I had received many phone calls about fixing the
problem.
I have been working on the problem for a couple of weeks now and
have come to understand that the problem has been around for a long
time, and little has been done to resolve the problem. The data
compression mode of the US robotics was not able to be used and people
were relying on ATARI to eventully fix the ROMs. After generating the
CTS Fix programs, alot of interest was stirred up to fix the problem
and it appeared to be time to fix the problem, once and for all.
The approach was to take a close look at TOS 1.4 and to determine
why it didn't work. I found only three minor problems with the
software. Two problems had to do with the software not being properly
initialized and a bug in the Rsconf() routine which would not let you
set CTS/RTS mode. I was able to get the RTS/CTS to work PERFECTLY
simply by properly initializing the MFP CTS active edge register based
on current CTS level, initializing a system variable which is used to
tell the software if the transmit port was enabled or disabled (also
based on current CTS level), and then setting the system variable to
enable CTS/RTS. Programs would work just fine until they tried to set
the flow control, which would disable CTS/RTS and cause XON/XOFF to be
enabled or disabled.
A final program was written to replace the RS-232 routines used by
the system. This was the only way to create some software which would
work with any version of ROMs. Since the other modes of handshaking
worked just fine, I decided to write some RS-232 routines which were
optimized for CTS/RTS flow control in hopes of also speeding up the
RS-232 routines. The resultant program is called TURBOCTS.PRG.
TURBOCTS is a program which can be either autobooted or run when
the RTS/CTS flow control is needed. Once the program has been loaded,
the RTS/CTS mode is enabled and can not be disabled without rebooting
the system. The Rsconf() command can be used to set the RS-232 speed
and play with the UART registers, but flow control settings will have
no effect. The program will also properly trap the printer operations
when the printer output is